WEEK 6: VERSION CONTROL

Monday, February 13th

Today we will…

  • Review Lab 5
  • Mini Lecture on text material
    • git/GitHub
  • Connect GitHub to RStudio
  • PA 6: Merge Conflicts – Collaborating within a GitHub Repo
  • Any lingering questions about Midterm

git/GitHub Basics

Git vs GitHub


  • Language for version control
  • Developed by Linus Torvalds (Linux, Android, Chrome OS)
  • Uses command line or GUI

  • Cloud-based hosting service
  • Basic services are free
  • Advanced services are paid (Similar to RStudio)

Why GitHub?

  1. A structured way for tracking changes to files over the course of a project.

  2. Makes it easy to have multiple people working on the same files at the same time.

  3. You can host a URL of fun things (like the class text, these slides, a personal website, etc.) with GitHub pages.

Think “track-changes” or “drop-box” history, but more structured.

Git Repositories

  • Think of this as a folder-directory for a single project (like your stat-331 folder!)

  • You may have code, documentation, data, TODO lists, and more associated with a project.

  • To create a repository, you can start with your local computer first, or you can start with the online repository first.

Actions in Git

Cloning a Repo

Committing

Git tracks changes to each file that it is told to monitor, and as the files change, you provide short labels describing what the changes were and why they exist (called “commits”).

Here, we commit the red line as a change to our file.

The log of these changes (along with the file history) is called your git commit history. This means you can always go back to old copies!

Pushing

Updates the copy of the repository on another machine (e.g. on GitHub) so that it has the most recent changes you’ve made to your machine.

Pulling

Updates your local copy of the repository (the copy on your computer) with the files that are “in the cloud” (on GitHub).

Pushing and Pulling

Merge Conflicts

Workflow

Starting a new project/local repo

  1. Clone the project or create a new repository
  2. Make some changes
  3. Commit the changes
  4. Pull any changes from the remote repository
  5. Resolve any merge conflicts
  6. Push the changes (and merged files)

Workflow

Starting a new project/local repo

  1. Clone the project or create a new repository
  2. Make some changes
  3. Commit the changes
  4. Pull any changes from the remote repository
  5. Resolve any merge conflicts
  6. Push the changes (and merged files)

Working with an existing local repo

  1. Pull the repo (especially if collaborating)
  2. Make some changes
  3. Commit the changes
  4. Pull any changes from the remote repository (again!)
  5. Resolve any merge conflicts
  6. Push the changes (and merged files)

Connect GitHub to RStudio

Rpackages we will need

Work in your terminal or an .Rscript for this…

  1. Install and load the {usethis} Rpackage
install.packages(usethis)
library(usethis)
  1. Install and load {gitcreds} RPackage
install.packages("gitcreds")
library(gitcreds)

Generate your PAT (Personal Access Token)

  1. Generate token
create_github_token()

Warning

GitHub really doesn’t like it when you do not have a PAT expiration date… but I don’t ever want to deal with it again. Make sure your expiration date is AT LEAST through the end of the quarter (60 days).

Store your PAT

  1. Copy your PAT

  1. Enter password or token: Paste PAT
gitcreds_set()

Verify PAT

You should be good to go! Let’s verify.

git_sitrep()

PA 6: Merge Conflicts

Collaborating within a GitHub Repo

Get into your groups!

Designate each person to one of the suits – you will be referencing it as you work through this activity.

Warning

If you only have 3 group members here, assign one person both and .

Flags

Please use sticky notes to indicate how your group is doing:

  • Green

    – we are ready to move on

  • Yellow

    – we’re figuring it out

  • Pink

    – Please help!!

Repository Setup

Creating a Repo (starting from GitHub)

  • Create a new Github repository titled stat-331-PA6
    • You can choose Public or Private
    • Select .gitignore template: R
  • Click on the Settings tab > Click on Collaborators > Add people
  • Add your other group members to the repository using their username or email

Accessing the Repo (cloud repo)

  • Verify repository invite in your email
  • Open the repository in Github

Cloning the Repo (local repo)

  • In Rstudio File > New Project > Version Control > Git (pause)
  • In GitHub, copy the HTTPS address from the repo <> Code and paste into the repository address line in RStudio
  • Click Browse and navigate to where you want to create your new project. I recommend creating this on your desktop.

Danger

Do not save this within your master stat 331 folder!!! We don’t want to embbed and Rproject within an RProject.

  • Create the project!

Collaborating in GitHub

Pulling Changes from the Repo

  • Create a new Quarto file (using the standard template)
    • Title the document “Practice Activity 6”
    • Resist the urge to add author names
    • Save the document as PA6.qmd
    • Add self-contained: true to the YAML
    • Render the document
  • Commit both the PA6.qmd and PA6.html files with an explanatory message such as “Created practice activity quarto file”
  • Push the changes to the repository

Pulling Changes from the Repo

  • Pull the changes that were made!

Everyone should now have the .qmd and .html files on their local computers!

Making a Change

  • Change the author name in the document to have everyone’s first names
  • Render the document
  • Commit the changes
  • Push the changes

Pushing Changes & Not Pulling

Do not pull the changes that were made!

Making the Same Change

  • Change the author name in the document to have everyone’s first and last names.
  • Render the document
  • Commit your changes
  • Push your changes

Danger

Oh no 😨 You got an error! Ugh. We forgot to pull before we started making changes 😢

Making The Same Changes

  • Pull the changes from the repo
  • Review the document with the merge conflict

Tip

Note how the conflicting lines are marked! You might need to submit this to Canvas 😄

  • Resolve the conflict with the preferred change
  • Commit your changes
  • Push the changes to the repository

Making The Same Changes

Do not pull the changes that were made!

Making Different Changes

  • Change the first code chunk to find the product of 13 times 13.
  • Render the document
  • Commit your changes
  • Push your changes

Warning

You will get an error, read it, and pull.

No merge conflicts should occur. Now push your changes.

Making Different Changes

Do not pull the changes that were made!

Making the Same Changes (Again)

  • Change the first code chunk to find the product of 11 times 11.
  • Render the document
  • Commit your changes
  • Push the changes to the repository

Danger

You will get an error. Ugh!!!! We forgot to pull again!

Making the Same Changes (Again)

  • Pull the changes from the repo
  • Review the document with the merge conflict
  • Clear the merge conflict by choosing the correct/preferred change
  • Commit your changes
  • Push you changes

Final Document

Pull, and observe the changes in your document.

Canvas Quiz Submission

Note

How does Git mark the start of lines with a merge conflict? Specifically, I want the four capital letter characters with which every conflict is marked.

Commit Tips

  • Use relatively short, but also informative commit messages.
  • Commit small blocks of changes. Work to commit every time you’ve accomplished a small task.
    • You’ll have small, bite-sized changes that are briefly described to serve as a record of what you’ve done (and what still needs doing)
    • When you mess up (or end up in a merge conflict) you will have a much easier time pinpointing the spot where things went bad, what code was there before, and (because you have nice, descriptive commit messages) how the error occurred.

Tips for avoiding merge conflicts

  • Always pull before you start working and always push after you are done working!

  • In general, if you follow the workflow for an existing local repo exactly, you only have problems if two of you are making local changes to the same line in the same file at the same time.

  • If you are working with collaborators in real time, pull, commit, and push often.

  • Git commits lines – lines of code, lines of text, etc.

    • Practice good code format and and put each sentence on its own line.

When all else fails…

Burn your local repo to the ground and clone again.

Questions about Midterm Exam?

To do…

  • PA 6: Merge Conflicts
    • Due Monday, 2/13 at end of class
  • Midterm Exam
    • In-class Wednesday

Wednesday, February 15th – Midterm Exam

To do…

  • NO CLASS MONDAY, 2/20

  • Final Project Group Contract

    • Due Thursday at 11:59pm

  • Final Project Proposals

    • DETAILS COMING SOON

  • Read Chapter 7: Writing Functions

    • Check-ins due Wednesday 2/22 at 8am